Anti-theft in firmware

ABSTRACT

Methods, systems and storage media are disclosed for enhanced system boot processing that authenticates boot code based on biometric information of the user before loading the boot code to system memory. For at least some embodiments, the bio -metric authentication augments authentication of boot code based on a unique platform identifier. The enhanced boot code authentication occurs before loading of the operating system, and may be performed during a Unified Extensible Firmware Interface (UEFI) boot sequence. Other embodiments are described and claimed.

BACKGROUND

Relatively portable computing systems, such as tablets, notebooks,laptops, netbooks, ultrabooks, cell phones, smart phones and otherhandheld devices, are often susceptible to theft. In some cases, thepurpose of the theft may be to take ownership of the device for thethief's use, or to sell the device to others. In order to protectagainst the situation where the thief desires to re-purpose the use of astolen device, it would be desirable to prevent boot of the device byanybody other than the original owner.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a phase diagram illustrating a UEFI boot sequence.

FIG. 2 is a flowchart illustrating at least one embodiment a method forencrypting firmware with biometric information.

FIG. 3 is phase diagram illustrating at least one embodiment of themethod of FIG. 2 during UEFI boot.

FIG. 4 is a flowchart illustrating at least one embodiment of anenhanced boot process with biometric-based authentication of firmware.

FIG. 5 is a phase diagram illustrating at least one embodiment of themethod of FIG. 4 during UEFI boot.

FIG. 6 is a block diagram illustrating firmware modules for performingat least one embodiment of biometric authentication of firmware duringboot.

FIG. 7 is a phase diagram illustrating functional firmware and softwaremodules to perform biometric encryption and decryption of firmwareduring UEFI boot.

FIG. 8 is a block diagram illustrated first and second systems inaccordance with at least one embodiment of the present invention.

FIG. 9 is a block diagram of a system in accordance with at least oneother embodiment of the present invention.

FIG. 10 is a block diagram of a system in accordance with at least oneother embodiment of the present invention.

DETAILED DESCRIPTION

Described embodiments provide anti-theft capabilities in firmware of acomputing device. More specifically, biometric information of a user isused to encrypt firmware necessary to boot the operating system (OS) ofa processing system. On subsequent boots, the firmware is decryptedduring boot using biometric information, such that only the user canboot the system. In this manner, repurposing of a stolen device can bethwarted.

Among current anti-theft technologies, many of them run in the OSenvironment as a software driver. These technologies may be thwarted ona stolen machine by uninstalling them, reinstalling the OS, or replacingthe hard disk with a new one. Other current anti-theft technologies arefirmware features. These act similarly to power-on password protection,and may be thwarted by changing a few bytes of firmware code to jump tobypass the authentication processing, or by burning a new copy offirmware to the stolen computing device from another device of the sametype.

The embodiments described herein provide advantages over several knownsecurity techniques because the embodiments provide a security mechanismthat is an inherent feature of the pre-OS firmware of the computingsystem, and may not be bypassed in the manner that some other securitymechanisms may be bypassed.

In order to avoid unauthorized re-purposing of a computing device,embodiments described herein thus address several security breachtechniques. For example, one such technique is to hack the ROM (ReadOnly Memory) of stolen computing device to reinstall a differentoperating system (“OS”). In computing systems without the embodimentsdescribed herein, this may be accomplished, for example, by re-flashingthe BIOS image to change the bootloader code so that a different OS isloaded during boot. In this manner, the OS power-on password of theoriginal owner may be bypassed. Embodiments described herein addressthis type of breach by performing a biometric authentication check inthe boot sequence prior to executing the bootloader code.

In computing systems that do not include any of the embodimentsdescribed herein, reflashing of the BIOS (Basic Input Output system)image may also be used to bypass security features provided by aseparate component of the system instead of by the CPU itself. Forexample, the BIOS image of a computing device may be re-flashed in orderto disable out-of-band security features. Such out-of-band securityfeatures may include those, for example, provided by a manageabilityengine, a trusted platform module (“TPM”,)or other standalone securitycomponent that is separate from the CPU. As an enhancement over such outof band security features, the embodiments described herein provideencrypted firmware components that prevent booting of the device in caseof authentication failure.

Another security breach technique addressed by embodiments describedherein is the swapping of memory in the computing system. In otherwords, in order to bypass encryption of storage on the computing device,an unauthorized user may change or switch out the user-replaceablestorage hardware on the computing device. In some cases, the storage maybe flash, but alternatively (or in addition) to flash, the replacedstorage hardware may be an internal hard drive or other storage mediumof the computing system.

Embodiments described herein address this type of breach by performing abiometric authentication check in the boot sequence prior to executingthe bootloader code, thereby prohibiting unauthorized access to storagemedia.

Another security breach technique addressed by the embodiments describedherein is disabling of security features that are embedded as an agentin an option ROM. See, e.g., Ortega, et. al, “De-Activate the RootKit:Attacks on BIOS Anti-theft Technologies,” Black Hat Briefings 2009 USA.Las Vegas, Nev. Jul. 30, 2009. These features do not run as part of atrusted computing base in the secure pre-OS processing associated withthe BIOS of a computing system but instead are loaded during later bootprocessing of option ROMs provided by third parties. As an enhancementover such ROM-based security features, the embodiments described provideencrypted firmware components that prevent booting of the device in caseof authentication failure. Accordingly, unauthorized access to optionROMs is prevented.

Referring now to FIG. 1, shown is a generalized depiction of a method100 for booting the OS of a computing system. At least one embodiment ofthe method 100 shown in FIG. 1 corresponds to the Unified ExtensibleFirmware Interface (UEFI) Specifications, such as UEFI 2.3.1c, which maybe found at ***.uefi.org (“www” replaced with asterisks to avoid livehyperlink). FIG. 1 illustrates that the method 100 begins block 110. Atblock 110, notification of a platform reset event is received. For atleast one embodiment, the platform reset event may be either a power-onevent or a warm start event (e.g., such as resumption from low-powerstates, such as S3 and/or S4 low-power states). The processing of block110 may correspond generally to a Security (SEC) phase 111 of the UEFIboot sequence. For such embodiments, block 110 includes not onlyreceiving a notification that the reset event has occurred, but alsoincludes performing some preliminary initialization processing. Forexample, for at least one embodiment, the following preliminaryprocessing may be performed at block 110 in response to the reset eventnotification: pre-RAM code (such as, e.g., execute in place (XIP) codein non-volatile memory) handles initial CPU initialization to create atemporary stack in the CPU cache.

FIG. 1 illustrates that, after reset processing 110 during the initialSecurity phase 111, processing proceeds to block 120. At block 120,platform hardware, such as the CPU and other system components, isinitialized. For some embodiments, examples of such other components mayinclude any one or more of the following: memory controller hardware,I/O controller hardware, chipset hardware (if a chipset is present),and/or motherboard hardware (if a motherboard is present). For at leastone embodiment, the platform initialization at block 120 may correspondto a Pre-EFI Initialization (“PEI”) phase 121 of the UEFI boot sequence.For at least one such embodiment, the processing at block 120 includesactions to finalize initialization of the CPU, and also may includediscovering the DRAM and discovering whether the reset event received atblock 110 was a cold start event or a warm start event (such as resumefrom a low power mode, e.g., S3/S4 sleep or hibernate mode). If theevent was a cold start event, processing proceeds from block 120 toblock 130. For some embodiments, if the event was a certain type of warmstart event (such as resume from a low power mode, such as S3 powerstate), processing skips from 120 over the processing at blocks 130,140, 150 and 160, and proceeds instead to OS resume/vector processing(not shown).

During a driver execution phase (DXE) 131, for at least one embodiment,the method 100 decrypts (see block 130) and loads (see block 140)drivers that are used to initialize the rest of system hardware. Thedecryption at block 130 is performed because UEFI drivers associatedwith the DXE phase are encrypted to further the goal of ensuring asecure boot. The DXE stage firmware is decrypted at block 130 using akey based on a platform identifier (see, e.g., platform ID key 180 ofFIG. 2). For at least one embodiment, the platform identifier is aunique identifier associated with the computing platform, such as aproduct serial number, MAC address of Ethernet device, TPM (TrustedComputing Module) key, or the like. For at least one embodiment, theplatform identifier has been used by the manufacturer to generate aplatform key, and the platform key has been used by the manufacturer toencrypt the firmware to be dispatched during the DXE phase 131. At block130, this same platform identifier is used during the boot processing100 to generate a platform ID key (see, e.g., platform ID key 180 ofFIG. 2). For at least one embodiment, the platform 1D key is generatedfrom the platform identifier by forming a hash of the platformidentifier.

The platform ID key is used to decrypt the executable DXE firmware atblock 130. Processing then proceeds to block 140. At block 140 theappropriate decrypted drivers are loaded into system memory anddispatched. Processing then proceeds to blocks 150, 160, and 170 forUEFI phases BDS (Boot Dev Select) 141, TSL (Transient System Load) 151,and RT (Run Time) 161, respectively. During one or more of these stages141, 151, 161, operating system code is loaded from non-volatile storageto volatile system memory. For one embodiment, such loading of OS codeoccurs at block 160 during TSL phase 151.

FIG. 2 is a flowchart illustrating at least one embodiment of a modifiedboot method 200. The method 200 includes encrypting of boot firmwareinstructions with biometric information. In this manner, subsequent bootsequences may include user authentication before loading bootinstructions, such as drivers, into memory (e.g., into volatile systemmemory) for execution.

The method 200 of FIG. 2 may be initiated, for example, upon the user'sfirst boot of a newly-purchased system. For such scenario, themanufacturer of the computing system may have, during manufacture,installed a flash manger that is set to know that the next power-onevent should invoke the method 200 of FIG. 2 to initialize the biometricauthentication.

Alternatively, the method 200 of FIG. 2 may be initiated by the user,after the initial first-time boot. Such alternative scenario may beinvoked, for example, by user selection of biometric authenticationinitialization via a user-controlled selection mechanism (for example, acontrol panel or settings option on the computing device). For at leastone such embodiment, the user-controlled mechanism is available toinitiate biometric authentication if it has not already been enabled(e.g., the manufacturer did not implement default processing to forcemethod 200 to be executed on first-time boot). Otherwise, a user maywish to change previously-initialized authentication information. Forsuch scenario, the user must first provide the old biometric information(processing not shown), before being authorized to proceed to block 222(discussed below) of the method 200 illustrated in FIG. 2. In otherwords, the thief of a system cannot bypass the authentication describedherein by trying to change the biometric information to his/her owninformation.

FIG. 2 illustrates that the method 200 begins with reset 210 andplatform initialization 220 processing, along the lines of processing110 and 120, respectively, discussed above in connection with FIG. 1.

From block 220, processing of the method 200 proceeds to block 222. Atblock 222, one or biometric input device(s) (see, e.g., 602 of FIGS. 6and 7) is initialized. The device(s) initialized at block 222 mayinclude one or more of the following devices: camera or other facialrecognition device, fingerprint scanner, retinal scanner, iris scanner,microphone or other voice scanner, brainwave scanner, DNA analyzer,handprint analyzer, or any other biometric input device. From block 222,processing proceeds to block 224.

At block 224, input from the user is received from the one or morebiometric input devices. It should be noted that multiple samples may bereceived from a single device, such as multiple views of a face, orprints from multiple fingers, or scans from both eyes. In this manner,multi-factor authentication may be supported for the firmwareencryption, including multiple readings of the same type (describedimmediately above) and/or single readings from multiple devices (suchas, e.g., combination of retinal scan and voice data for theencryption). The received information may be stored in digitized format.From block 224, processing proceeds to block 230.

At block 230, the digitized biometric information is used to generate apersonal key that corresponds to the biometric data of the user. Theypersonal key may be generated at block 230, for example, by generating ahash value based on the digitized biometric information of the user thatwas collected at block 224. From block 230, processing then proceeds toblock 250.

At block 250, executable firmware instructions are encrypted. For atleast one embodiment, this is accomplished by encrypting the firmwarevolume on which DXE phase instructions reside. The encryption at block250 is performed using the personal key generated at block 230 alongwith a platform ID key 180 generated from the platform identifier,discussed above. The encrypted instructions may be loaded to into devicefirmware to overwrite any existing instructions on the firmware volume.From block 250, processing then ends at block 280. For at least onealternative embodiment, processing may proceed from block 250 tooptional block 255. The optional nature of block 255 is denoted in FIG.2 with broken lines.

At block 255, it is determined whether the user wishes to continue withthe boot process. If not, processing ends at block 180. Such processingmay occur, for example, when the user only wishes to perform initialencryption processing, but does not currently wish to actually boot anduse the computing device. The user's wishes may be ascertained at block255 via any known method, including keyboard input, user screen input,voice input, or the like.

If the user wishes to continue with the boot process, processingproceeds from block 255 to boot processing blocks 260, 270 and 275, inorder to load and begin execution of the OS.

The processing of method 200 illustrated in FIG. 2 may be implemented,for at least one embodiment, as part of a UEFI boot process. Turning toFIG. 3, shown is the method 200 of FIG. 2 as applied to the phases 311,321, 331, 341, 351, 361 of a UEFI boot sequence. FIG. 3 illustrates thatthe bulk of the method 200 is performed during the DXE phase 331.

In particular, FIG. 3 illustrates that block 210 of method 200 isperformed during the SEC phase 311 and that block 220 is performedduring the PEI phase 321. From block 220, processing proceeds to block222.

FIG. 3 illustrates that blocks 222, 224, 230, 250 and 255 are performedduring the DXE phase 331. That is, it is during the DXE phase 331 thatUEFI firmware is encrypted with a personal key based on biometricinformation of the user (along with a platform identifier). Processingblocks 260, 270, and 275 are then performed during the BDS phase 341,TSL phase 351, and RT phase 361, respectively, if the determination atblock 255 evaluates to a “true” value. Otherwise, processing ends atblock 280.

FIG. 4 is a flowchart illustrating at least one embodiment of anenhanced boot process with biometric-based decryption of firmware. Forat least one embodiment, it is assumed that the method 400 of FIG. 4 isperformed on a computing system on which method 200 of FIG. 2 hasalready been performed. That is, FIG. 4 illustrates a method ofdecrypting firmware, using biometric information of a user, after themethod 200 illustrated in FIG. 2 has already been performed on thesystem to encrypt the firmware using biometric information of the user.In such manner, the method 400 may be used to authenticate bootinstructions, such as drivers, before such drivers are loaded intomemory (e.g., loaded into volatile system memory) for execution duringthe boot sequence.

FIG. 4 illustrates that the method 400 includes several processingblocks 410, 420, 430, 440, 450, 460, 470 that proceed along the lines ofthose described above in connection with the method 100 of FIG. 1 (110,120, 130, 140, 150, 160, 170 respectively). However, FIG. 4 illustratesthat the normal boot sequence 100 has been enhanced to take into accountbiometric decryption. Thus, FIG. 4 illustrates that, at block 425, it isdetermined whether enhanced biometric authentication has been enabledfor the device. That is, for some embodiments, the user may havepreviously chosen to forgo such encryption on the instant system.Similarly, the manufacturer may have chosen to disable the feature. Insuch case, processing proceeds to block 430. It should be noted that, ifthe evaluation at block 430 evaluates to a “false” value, then theprocessing blocks executed for the method 400 shown in FIG. 4 correspondto the normal boot sequence (e.g., 110, 120, 130, 140, 150, 160, 170)illustrated in FIG. 1. On the other hand, if the evaluation at block 425evaluates to a “true” value, then processing proceeds to block 432 inorder to begin biometric decryption processing.

At block 432, biometric input devices are initialized. For at least oneembodiment, the processing of block 432 proceeds along the lines of theprocessing of block 222 described above in connection with FIG. 2.Processing then proceeds from block 432 to block 434. At block 434,biometric information of the user is collected. For at least oneembodiment, the processing of block 434 proceeds along the lines of theprocessing of block 224 discussed above in connection with FIG. 2.Processing then proceeds to block 436.

At block 436, a personal key is generated based on the biometricinformation collected at block 434. Again, the processing for at leastone embodiment of block 436 proceeds along the lines of that of block230, discussed above in connection with FIG. 2. Processing then proceedsfrom block 436 to block 438.

At block 438, the previously-encrypted firmware volume (see FIG. 2) isdecrypted using the personal key generated at block 436. For at leastone embodiment, the decryption is based on the platform ID key 180 aswell as the personal key. For at least one other embodiment, theencryption may be based on additional information. Such additionalinformation may include other factors such as password(s) orpassphrase(s) (“what you know”), a token, such as a USB dongle, smartcard or other device (“what you have”), and/or location information,such as GPS data or geofencing data (“where you are”). For at least oneembodiment, any such additional information may be captured as anadditional key to be used for decryption along with (or instead of) thebiometric personal key. For at least one other embodiment, theadditional information may be included in the personal key. For any ofthese embodiments, it is to be understood that the user-basedinformation (including biometric data, as well as optional “what youknow”, “what you have”, and “where you are” data) used for theencryption at block 438 was also previously used for the encryptionperformed at block 250 of FIG. 2.

FIG. 4 illustrates that, due to the processing at blocks 432, 434, 436and 438, the firmware volume cannot be decrypted during the boot processwithout the physical presence of the user. In this manner, the computingsystem cannot boot the OS without the physical presence of the user,making the device useless if it has been stolen. In addition, becausethe encryption/decryption illustrated at blocks 250 (FIGS. 2) and 438(FIG. 4) also use the platform ID key, additional security ismaintained. That is, the user of a first computing system cannot burn acopy of firmware from a second computing system into first computingsystem, even if the user owns both systems. This is due to the fact thatthe platform identifier is unique among computer systems.

If the decryption operation at block 438 is successful, normal bootprocessing is performed at blocks 440, 450, 460 and 470.

However, if the decryption operation is not successful, processing endsat block 458. Before ending, however, optional block 456 may beperformed. At block 456, it is determined whether the decryption shouldbe re-attempted. Such determination may be based on a default setting,or may be based on selection input solicited from the user. In anyevent, if retry is to be performed, processing proceeds to block 434 sothat biometric information may be collected for an additional decryptionattempt.

The processing of method 400 illustrated in FIG. 4 may be implemented,for at least one embodiment, as part of a UEFI boot process. Turning toFIG. 5, shown is the method 400 of FIG. 4 as applied to the phases 311,321, 331, 341, 351, 361 of a UEFI boot sequence. FIG. 5 illustrates thatthe bulk of the method 400 is performed during the DXE phase 331.

In particular, FIG. 5 illustrates that block 410 of method 400 isperformed during the SEC phase 311 and that block 420 is performedduring the PEI phase 321. From block 420, processing proceeds to block425.

FIG. 5 illustrates that blocks 425, 430, 432, 434, 436, 438, and 440, aswell as optional block 456, are performed during the DXE phase 331. Thatis, it is during the DXE phase 331 that UEFI firmware is decrypted usingbiometric information of the user (along with platform identifier).Processing blocks 450, 460, and 470 are then performed during the BDSphase 341, TSL phase 351, and RT phase 361, respectively, if thedetermination at block 456 evaluates to a “true” value. Otherwise,processing ends at block 458.

FIG. 6 is a block diagram illustrating modules 630 and other systemelements for performing at least embodiment of biometric authenticationof firmware during boot. For example, modules 630 may includeinstructions to perform embodiments of the encryption blocks 222, 224,230, 250 illustrated in FIGS. 2 and 3, and may also include instructionsto perform embodiments of the decryption blocks 430, 432, 434, 436, 438illustrated in FIGS. 4 and 5. Accordingly, embodiments of the inventioninclude machine-accessible storage media containing instructions forperforming the operations discussed herein. Such embodiments may also bereferred to as computer program products.

FIG. 6 illustrates that the modules 630 include at least one or more ofthe following: a device initializer 604, an input collector 606, a keygenerator 608, an encryptor module 612, and a decryptor module 614. Forat least one embodiment, such modules 630 are firmware modules stored inRead Only Memory (ROM) of a computing device and executed during theboot process before the OS is loaded. For example, one or moreinstructions of the device analyzer 604 may be executed during boot toperform the processing of block 222 shown in FIGS. 2 and 3, and toperform the processing of block 432 shown in FIGS. 4 and 5. One or moreinstructions of the input collector 606 may be executed to perform theprocessing of block 224 shown in FIGS. 1 and 3, and to perform theprocessing of block 434 shown in FIGS. 4 and 5. One or more instructionsof the key generator 608 may be executed to perform the processing togenerate a personal key 610, as shown at block 230 of FIGS. 2 and 3 andat block 436 shown in FIGS. 4 and 5.

One or more instructions of the encryptor module 612 may be executed toencrypt boot instructions as described in connection with block 250shown in FIGS. 2 and 3. For at least one embodiment, the encryptionprocessing 250 performed by the encryptor module 612 may be applied to afirmware volume that contains UEFI driver instructions.

One or more instructions of the decryptor module 614 may be executed todecrypt boot instructions as described in connection with block 438shown in FIGS. 4 and 5. For at least one embodiment, the encryptionprocessing 438 performed by the decryptor module 614 may be applied to afirmware volume that contains UEFI driver instructions.

FIG. 6 further illustrates that the modules 630 may be applied to inputdata to perform the functions described herein and to generate outputinformation. Accordingly, one or more of the modules 630 may receiveinput from other components of the computing system. For example, FIG. 6illustrates that the encryptor module 612 and decryptor module 614 mayboth receive the platform ID 680 from the computing system.

The input collector 606 may receive biometric information from one ormore biometric device(s) 620. The optional nature of additionalbiometric devices is denoted in FIG. 6 with broken lines. For at leastone embodiment, biometric devices may include one or more of any or allof the following: camera or other facial recognition device, fingerprintscanner, retinal scanner, iris scanner, microphone or other voicescanner, brainwave scanner, DNA analyzer, handprint analyzer, or anyother biometric input device.

One or more of the modules 630 may provide output data or signals toother components of the computing system. For example, FIG. 6illustrates that the device initializer 604 may provide initializationsignals and/or data to one or more biometric device(s) 602. Also, thekey generator module 608 may generate a key 610 based at least in parton biometric data of the user, and may provide such key 610 to othermodules such as the encryptor module 612 and the decryptor module 614.

Although discussed as herein primarily as ROM firmware instructions,embodiments of the modules 630 disclosed herein may be implemented inhardware, software, firmware, or a combination of such implementationapproaches. Embodiments may be implemented as computer instructionsexecuting on programmable systems comprising at least one processor, adata storage system (including volatile and/or non-volatile memoryand/or storage elements), at least one input device (such as a keyboard,touchscreen or the like), and at least one output device (such as anintegral display screen or a peripheral display device, such asmonitor).

Such machine-accessible storage media may include, without limitation,tangible non-transitory arrangements of particles manufactured or formedby a machine or device, including storage media such as hard disks, anyother type of disk including floppy disks, optical disks, compact diskread-only memories (CD-ROMs), compact disk rewritables (CD-RWs), andmagneto-optical disks, semiconductor devices such as read-only memories(ROMs), random access memories (RAMs) such as dynamic random accessmemories (DRAMs), static random access memories (SRAMs), erasableprogrammable read-only memories (EPROMs), flash memories, electricallyerasable programmable read-only memories (EEPROMs), magnetic or opticalcards, or any other type of media suitable for storing electronicinstructions.

The modules 630 illustrated in FIG. 6 may be executed, for at least oneembodiment, as part of a UEFI boot process. Turning to FIG. 7, shown isa phase diagram illustrating functional firmware and software modules toperform biometric-based authentication of firmware during UEFI boot.FIG. 7 illustrates a Startup Module 710 and a PEI Core Module 720.Startup Module 710 may be executed, for at least one embodiment, toperform the processing of blocks 110, 210, and 410 as discussed above inconnection with FIGS. 1, 2 & 3, and 4 & 5, respectively. Such processingmay be performed during the SEC phase 311 of the UEFI boot sequence.

Similarly, PEI Core Module 720 may be executed, for at least oneembodiment, to perform the processing of blocks 120, 220, and 420 asdiscussed above in connection with FIGS. 1, 2 &3, and 4 & 5,respectively. Such processing may be performed during the PEI phase 321of the UEFI boot sequence.

FIG. 7 also illustrates Authentication Module 630. The AuthenticationModule 630 may receive various inputs, including biometric data from oneor more biometric device(s) 620, and also a platform identifier.Authentication Module 630 may be executed, as discussed above inconnection with FIG. 6, to perform biometric authentication of firmwaredrivers to be executed during the boot process. Such processing may beperformed during the DXE phase 331 of the UEFI boot sequence.

FIG. 7 also illustrates additional modules 740, 750, 760, 770 to beexecuted during phases 331, 341, 351, and 361, respectively, of the OSboot process. Such modules may include firmware modules, but also mayinclude software programs. For example, the OS 770 may be implemented asa software program rather than as firmware instructions.

Any of the modules implemented as software programs (e.g., 770) may beimplemented in a high level procedural or object oriented programminglanguage to communicate with a processing system. The programs may alsobe implemented in assembly or machine language, if desired. In fact, themechanisms described herein are not limited in scope to any particularprogramming language. In any case, the language may be a compiled orinterpreted language.

Referring now to FIG. 8, shown are block diagrams of a first system 800a and a second system 800 b, each of which may perform embodiments ofthe enhanced boot processing described above. For purposes of thisapplication, a processing system includes any system that has aprocessor, such as, for example; a digital signal processor (DSP), amicrocontroller, an application specific integrated circuit (ASIC), agraphics processing unit, or a microprocessor.

As shown in FIG. 8, the first system 800 a may include one or moreprocessing elements 810, 815, which are coupled to graphics memorycontroller logic (GMC) 820. The optional nature of additional processingelements 815 is denoted in FIG. 8 with broken lines.

Each processing element 810, 815 may be a single core or may,alternatively, include multiple cores. The processing elements 810, 815may, optionally, include other on-die elements besides processing cores,such as integrated memory controller and/or integrated I/O controllogic. Also, for at least one embodiment of the first system 800 a, thecore(s) of the processing elements 810, 815 may be multithreaded in thatthey may include more than one hardware thread context per core.

FIG. 8 illustrates that the GMC 820 may be coupled to a memory 830 thatmay be, for example, a dynamic random access memory (DRAM). For at leastsome embodiments, the GMC 820 may be a chipset, or a portion of achipset. Alternatively, the controller logic of the GMC may beintegrated with other components of the system such as, for example, ina system-on-a-chip (SOC) configuration. The GMC 820 may communicate withthe processor(s) 810, 815 and control interaction between theprocessor(s) 810, 815 and memory 830.

The GMC 820 may also act as an accelerated bus interface between theprocessor(s) 810, 815 and other elements of the system 800 a. For atleast one embodiment, the GMC 820 communicates with the processor(s)810, 815 via a multi-drop bus, such as a frontside bus (FSB) 895. Forother embodiments (see, e.g., FIGS. 9 and 10), the GMC 820 communicateswith the processors(s) 810, 815 via a point-to-point interconnect.

Furthermore, GMC 820 is coupled to a display 840 (such as, e.g., a flatpanel display or touch-sensitive display). GMC 820 may include anintegrated graphics accelerator. GMC 820 is further coupled toinput/output (I/O) controller logic (IC) 850, which may be used tocouple various peripheral devices to system 800 a. Shown for example isan external graphics device 860, which may be a discrete graphicsdevice, coupled to IC 850, along with other peripheral device(s) 870,such as one or more keyboard, mouse, or numeric keypad.

Alternatively, additional or different processing elements may also bepresent in the first system 800 a. For example, any of the featuresdiscussed immediately below in connection with the second systemembodiment 800 b may be included in the first system 800 a. Also,additional processing element(s) 815 may include additionalprocessors(s) that are the same as processor 810, additionalprocessor(s) that are heterogeneous or asymmetric to processor 810,accelerators (such as, e.g., graphics accelerators or digital signalprocessing (DSP) units), field programmable gate arrays, or any otherprocessing element. There can be a variety of differences between thephysical resources 810, 815 in terms of a spectrum of metrics of meritincluding architectural, microarchitectural, thermal, power consumptioncharacteristics, and the like. These differences may effectivelymanifest themselves as asymmetry and heterogeneity amongst theprocessing elements 810, 815. For at least one embodiment, the variousprocessing elements 810, 815 may reside in the same die package.

FIG. 8 also illustrates that the second system 800 b may include one ormore processing elements 811. As with the first system 800 a illustratedin FIG. 8, system 800 b is an electronic device that may be implementedusing any suitable hardware and/or software to configure electronicdevice 800 b as desired. FIG. 8 illustrates that, for one embodiment, anexample system 800 b includes a touch-sensitive display device 802 andone or more processors 811 coupled to system control logic 804. Theexample system 800 b may also include system memory 830 coupled tosystem control logic 804. System control logic 804 may also be coupledto non-volatile memory and/or storage device(s) 835 and may also becoupled to one or more communications interfaces 806.

Touch-sensitive display device 802 (also referred to herein as a“touchscreen”) may be implemented using any suitable touch-sensitivetechnology such as, for example and without limitation, capacitive,resistive, surface acoustic wave (SAW), infrared, and optical imaging.The touch-sensitive technology used for touch-sensitive display device802 for one embodiment may not require actual touching over its surface,but rather may sense the presence of an object near the surface. Suchtechnology may nevertheless be considered touch-sensitive because suchtechnology will similarly sense an object that actually touches over thesurface of the display device 802 and because such surface is likely tobe actually touched when electronic device 800 b is used.Touch-sensitive display device 802 for one embodiment may be implementedusing any suitable multi-touch technology. Touch-sensitive displaydevice 802 includes a display that may be implemented using any suitabledisplay technology, such as that for a liquid crystal display (LCD) forexample. System control logic 804 for at least one embodiment mayinclude one or more graphics controllers to provide one or more displayinterfaces to touch-sensitive display device 802.

System control logic 804 for at least one embodiment may include anysuitable interface controllers to provide for any suitable interface toat least one processor 811 and/or to any suitable device or component incommunication with system control logic 804.

System control logic 804 for at least one embodiment may include one ormore memory controllers to provide an interface to system memory 830.System memory 830 may be used to load and store data and/orinstructions, for example, during operation of system 800 b. For atleast one embodiment, system memory 830 may be used to store anysuitable software 832, such as any suitable driver software, applicationsoftware, and/or operating system software (see, e.g., operating system770 of FIG. 7). System memory 830 for one embodiment may include anysuitable volatile memory, such as suitable dynamic random access memory(DRAM) for example.

System control logic 804 for at least one embodiment may include one ormore input/output (I/O) controllers to provide an interface totouch-sensitive display device 802, non-volatile memory and/or storagedevice(s) 835, and/or communications interface(s) 806.

Non-volatile memory and/or storage device(s) 835 may be used to storedata and/or instructions 837. For example non-volatile memory and/orstorage device(s) 835 may store firmware modules along the lines ofmodules 604, 606, 6089, 612, 614 illustrated in FIG. 6. For suchembodiments, instructions 837 may correspond to Authentication Module630 illustrated in FIGS. 6 and 7.

Non-volatile memory and/or storage device(s) 835 may include anysuitable non-volatile memory, such as flash memory for example, and/ormay include any suitable non-volatile storage device(s), such as one ormore hard disk drives (HDDs), one or more compact disc (CD) drives,and/or one or more digital versatile disc (DVD) drives for example.Non-volatile memory and/or storage device(s) 835 may include, for atleast one embodiment, non-volatile Read-Only Memory (ROM) that storesinstructions for boot processing (see, e.g., modules 630 of FIG. 6 andthe boot processing of FIGS. 1, 2, 3, 4 and 5).

Communications interface(s) 806 may provide an interface for system 800b to communicate over one or more networks and/or with any othersuitable device. Communications interface(s) 806 may include anysuitable hardware and/or firmware. Communications interface(s) 806 forone embodiment may include, for example, a network adapter, a wirelessnetwork adapter, a telephone modem, and/or a wireless modem. Forwireless communications, communications interface(s) 806 for oneembodiment may use one or more antennas 808.

System control logic 804 for at least one embodiment may include one ormore input/output (I/O) controllers to provide an interface to anysuitable input/output device(s) such as, for example, an audio device tohelp convert sound into corresponding digital signals and/or to helpconvert digital signals into corresponding sound, a camera, a camcorder,a printer, and/or a scanner.

For at least one embodiment, at least one processor 811 may be packagedtogether with logic for one or more controllers of system control logic804. For one embodiment, at least one processor 811 may be packagedtogether with logic for one or more controllers of system control logic804 to form a System in Package (SiP). For one embodiment, at least oneprocessor 811 may be integrated on the same die with logic for one ormore controllers of system control logic 804. For one embodiment, atleast one processor 811 may be integrated on the same die with logic forone or more controllers of system control logic 804 to form a System onChip (SoC).

Although described for one embodiment as being used in system 800 b,touch touch-sensitive display device 802 for other embodiments may beused in other system configurations.

Referring now to FIG. 9, shown is a block diagram of a third systemembodiment 900 in accordance with an embodiment of the presentinvention. As shown in FIG. 9, multiprocessor system 900 is apoint-to-point interconnect system, and includes a first processingelement 970 and a second processing element 980 coupled via apoint-to-point interconnect 950. As shown in FIG. 9, each of processingelements 970 and 980 may be multicore processors, including first andsecond processor cores (i.e., processor cores 974a and 974b andprocessor cores 984a and 984b).

Alternatively, one or more of processing elements 970, 980 may be anelement other than a processor, such as an accelerator or a fieldprogrammable gate array.

While shown with only two processing elements 970, 980, it is to beunderstood that the scope of the appended claims is not so limited. Inother embodiments, one or more additional processing elements may bepresent in a given processor.

First processing element 970 may further include a memory controllerlogic (MC) 972 and point-to-point (P-P) interfaces 976 and 978.Similarly, second processing element 980 may include a MCH 982 and P-Pinterfaces 986 and 988. As shown in FIG. 9, memory controller logic 972and 982 couple the processors to respective memories, namely a memory932 and a memory 934, which may be portions of main memory locallyattached to the respective processors.

First processing element 970 and second processing element 980 may becoupled to I/O control logic 990 via P-P interconnects 952 and 954,respectively. As shown in FIG. 9, 1/0 control logic 990 may include P-Pinterfaces 994 and 998.

Furthermore, I/O control logic 990 includes an interface 992 to coupleI/O control logic 990 with a high performance graphics engine 938. Inone embodiment, bus 939 may be used to couple graphics engine 938 to I/Ocontrol logic 990. Alternately, a point-to-point interconnect 939 maycouple these components.

In turn, I/O control logic 990 may be coupled to a first bus 916 via aninterface 996. In one embodiment, first bus 916 may be a PeripheralComponent Interconnect (PCI) bus, or a bus such as a PCI Express bus oranother third generation I/O interconnect bus, although the scope of theappended claims are not so limited.

As shown in FIG. 9, various I/O devices 914 may be coupled to first bus916, along with a bus bridge 918 which couples first bus 916 to a secondbus 910. In one embodiment, second bus 910 may be a low pin count (LPC)bus. Various devices may be coupled to second bus 910 including, forexample, a keyboard and/or mouse 912, communication devices 916 and adata storage unit 918 such as a disk drive or other mass storage devicewhich may include code 930, in one embodiment. The code 930 may includeinstructions for performing embodiments of one or more of the methodsdescribed above. Further, an audio I/O 914 may be coupled to second bus910. Note that other architectures are possible. For example, instead ofthe point-to-point architecture of FIG. 9, a system may implement amulti-drop bus or another such architecture.

Referring now to FIG. 10, shown is a block diagram of a fourth systemembodiment 1000 in accordance with an embodiment of the presentinvention. Like elements in FIGS. 9 and 10 bear like reference numeralsand certain aspects of FIG. 9 have been omitted from FIG. 10 in order toavoid obscuring other aspects of FIG. 10.

FIG. 10 illustrates that the processing elements 970, 980 may includeintegrated memory and I/O control logic (“CL”) 1072 and 1082,respectively. For at least one embodiment, the CL 1072, 1082 may includememory controller logic. In addition. CL 1072, 1082 may also include I/Ocontrol logic. FIG. 10 illustrates that not only are the memories 932,934 coupled to the CL 1072, 1082, but also that I/O devices 1044 mayalso be coupled to the control logic 1072, 1082. Legacy I/O devices 1015may be coupled to the I/O subsystem 990 or to a chipset, if one ispresent.

Presented herein are embodiments of methods and systems for enhancedsystem boot processing that is faster to launch the OS because it doesnot interrogate I/O devices for possible interruption, but that also maybe modified to interrogate such devices based on a user selectionmechanism. While particular embodiments of the present invention havebeen shown and described, it will be obvious to those skilled in the artthat numerous changes, variations and modifications can be made withoutdeparting from the scope of the appended claims.

Accordingly, one of skill in the art will recognize that changes andmodifications can be made without departing from the present inventionin its broader aspects. The appended claims are to encompass withintheir scope all such changes, variations, and modifications that fallwithin the true scope and spirit of the present invention.

The following examples pertain to embodiments in accordance with thisSpecification. One or more embodiments may provide a method forperforming biometric authentication of boot modules during boot of theoperating system for a computing system. The method may include:performing initial operations of a boot sequence in a computing system,responsive to receiving notification of a reset event;

decrypting boot sequence code using a plurality of keys, wherein theplurality of keys includes at least one key generated from biometricinformation of a user of the computing system; responsive to thedecrypting, performing additional operations of the boot sequence,wherein the additional operations include loading of operating systemcode into system memory of the computing system; and terminating theboot sequence without loading the operating system code if thedecrypting is unsuccessful.

In an example of one or more embodiments, the boot sequence may be aUEFI boot sequence. For such embodiments, the decrypting is performedduring a driver execution environment phase of the UEFI boot sequence.The decrypting for such embodiments may further comprise decrypting ofUEFI driver code.

In an example of one or more embodiments, the initial operations of theboot sequence include one or more operations to initialize a processorof the computing system.

In an example of one or more embodiments, the method may further includeinitializing one or more biometric devices. The method may furtherinclude collecting the biometric information from one or more biometricdevices.

In an example of one or more embodiments, the plurality of keys furtherincludes at least one key generated from information unique to thecomputing system.

One or more embodiments may provide at least one machine-accessiblestorage medium comprising one or more instructions that when executed bya processor cause a computing device to: receive notification of a resetevent; receive, from one or more biometric device, biometric informationassociated with a user; encrypt instructions, to be executed during aboot sequence, based on said biometric information; and performadditional processing to load the operating system; wherein saidencrypting is further based on a unique identifier associated with thecomputing device and is to be performed prior to loading of an operatingsystem.

For at least one such embodiment, the encrypting is to be performedduring a driver execution environment phase of a UEFI boot sequence.

For at least one other such embodiment, encrypting is to be furtherbased on one or more additional data associated with the user. The oneor more additional data further comprises one or more of: (a) possessionof a token, (b) password, (c) passphrase, and (d) location of the user.

In another example of one or more embodiments of the at least onecomputer-readable medium, one or more additional instructions whenexecuted cause the computing device to: perform one or more platforminitialization instructions; and initialize the one or more biometricdevices.

One or more embodiments may provide at least one othermachine-accessible storage medium comprising one or more instructionsthat when executed by a processor cause a computing device to: receivenotification of a reset event; receive, from one or more biometricdevice, biometric information associated with a user; decryptinstructions, to be executed during a boot sequence, based on saidbiometric information; and perform additional processing to load theoperating system; wherein said decrypting is to be further based on aunique identifier associated with the computing device and is to beperformed prior to loading of an operating system.

In another example of one or more embodiments of the at least one othercomputer-readable medium, one or more additional instructions whenexecuted cause the computing device to: perform one or more platforminitialization instructions; and initialize the one or more biometricdevices.

For at least one such embodiment, the encrypting is to be performedduring a driver execution environment phase of a UEFI boot sequence.

For at least one other such embodiment, encrypting is to be furtherbased on one or more additional data associated with the user. The oneor more additional data further comprises one or more of: (a) possessionof a token, (b) password, (c) passphrase, and (d) location of the user.

One or more embodiments may provide a system that is to performbiometric authentication of boot modules. An example of such anembodiment includes a processor; a non-volatile memory coupled to theprocessor; and a system memory coupled to the processor; wherein saidnon-volatile memory includes one or more instructions for: generating afirst key, based on biometric information of a user; authenticatinginstructions stored in the non-volatile memory; and loading theauthenticated instructions from the non-volatile memory into thevolatile memory; wherein said authenticating is based on the first keyand a unique identifier associated with the system.

For at least one such example system embodiment, said authenticatedinstructions are instructions to be executed prior to loading ofoperating system code into the system memory.

For at least one other such example system embodiment, said uniqueidentifier is a serial number associated with the system.

For at least one other such example system embodiment, said uniqueidentifier is a trusted platform module key.

For at least one other such example system embodiment, said biometricinformation is a fingerprint.

For at least one other such example system embodiment, said biometricinformation is an image of the user's face.

For at least one other such example system embodiment, saidauthenticated instructions further comprise instructions associated withone or more drivers. For at least one such embodiment, said instructionsstored in non-volatile memory further comprise instructions associatedwith one or more UEFI drivers.

For at least one other such example system embodiment, said non-volatilememory includes one or more instructions for generating a second key,based on the unique identifier.

For at least one other such example system embodiment, the system ofclaim 11, wherein said decrypting is to be further based on additionaldata associated with the user. For at least one such embodiment, saidadditional data associated with the user further comprises a password.For at least one such embodiment, said additional data associated withthe user further comprises a passphrase. For at least one suchembodiment, said additional data associated with the user furthercomprises user location information.

1-75. (canceled)
 76. At least one non-transitory machine accessible storage medium including one or more sequences of instructions, the sequences of instructions including instructions which when executed cause a computing device to: receive notification of a reset event; receive, from one or more biometric devices, biometric information associated with a user; encrypt firmware instructions to be executed during a boot sequence, wherein encryption is based on at least three credentials including a unique identifier associated with the computing device, the biometric information, and user-based information, wherein encryption is performed during the boot sequence; and perform additional processing to load the operating system.
 77. The storage medium of claim 76, wherein the user-based information includes possession of a token.
 78. The storage medium of claim 76, wherein the user-based information includes a password.
 79. The storage medium of claim 76, wherein the user-based information includes a passphrase.
 80. The storage medium of claim 76, wherein the user-based information includes a location of the user.
 81. The storage medium of claim 76, wherein the unique identifier includes a product serial number.
 82. The storage medium of claim 76, wherein the unique identifier includes a media access control (MAC) address of an Ethernet device.
 83. The storage medium of claim 76, wherein the unique identifier includes a product serial number.
 84. The storage medium of claim 76, wherein the unique identifier includes a Trusted Platform Module (TPM) key.
 85. The storage medium of claim 76, wherein encryption is to be performed prior to loading of an operating system.
 86. The storage medium of claim 76, wherein encryption is to be performed during a driver execution environment phase of the boot sequence.
 87. The storage medium of claim 76, the instructions further comprising instructions which when executed cause the computing device to: perform one or more platform initialization instructions, and initialize the one or more biometric devices.
 88. At least one non-transitory machine accessible storage medium including one or more sequences of instructions, the sequences of instructions including instructions which when executed cause a computing device to: receive notification of a reset event; receive, from one or more biometric devices, biometric information associated with a user; decrypt firmware instructions to be executed during a boot sequence, said decrypting based on at least three credentials including a unique identifier associated with the computing device, the biometric information, and user-based information, wherein decryption is performed during the boot sequence; and perform additional processing to load the operating system.
 89. The storage medium of claim 88, the instructions further comprising instructions which when executed cause the computing device to: perform one or more platform initialization instructions, and initialize the one or more biometric devices.
 90. The storage medium of claim 89, wherein the user-based information comprises one or more of: (a) possession of a token, (b) password, (c) passphrase, and (d) location of the user.
 91. A method, comprising: performing initial operations of a boot sequence in a computing system, responsive to receiving notification of a reset event; decrypting boot sequence firmware code during a driver execution environment phase of a boot sequence using at least three credentials including a unique identifier associated with the computing device, the biometric information, and data associated with a user, the biometric information comprises readings from one or more biometric devices; responsive to the decrypting, performing additional operations of the boot sequence, wherein the additional operations include loading of operating system code into system memory of the computing system; and terminating the boot sequence without loading the operating system code if the decrypting is unsuccessful.
 92. The method of claim 91, wherein the boot sequence is a UEFI boot sequence.
 93. The method of claim 91, wherein the decrypting of boot sequence firmware code further comprises decrypting of UEFI driver code.
 94. The method of claim 91, wherein said initial operations of the boot sequence include one or more operations to initialize a processor of the computing system.
 95. The method of claim 91, further comprising: initializing one or more biometric devices.
 96. The method of claim 91, further comprising: collecting the biometric information from one or more biometric devices. 